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ABSTRACT 


The  modern  engineer  has  a  myriad  of  new  tools  to  assist  in  the  design  and 
implementation  of  ever  increasingly  complex  control  systems.  A  promising  emerging 
technology  is  rapid  prototyping.  By  totally  integrating  the  development  process,  a  Rapid 
Prototyping  System  (RPS)  takes  the  designer  from  initial  concept  to  testing  on  actual 
hardware  in  a  systematic,  logical  sequence.  At  the  Naval  Postgraduate  School  (NPS),  we 
have  applied  the  concept  of  rapid  prototyping  to  the  discipline  of  flight  control. 

The  NPS  RPS  consists  of  a  commercially  available  rapid  prototyping  software 
suite  and  open  architecture  hardware  to  permit  the  greatest  possible  range  of  control  and 
navigation  projects.  The  RPS  is  crucial  in  that  it  allows  students  to  participate  in  projects 
from  the  initial  concept  to  the  flight  testing  phase  of  the  design  process.  This  thesis  will 
describe  in  detail  two  of  these  projects;  the  development  of  an  Airspeed  Controller  using 
the  RPS  tools;  and  the  integration  of  a  Voice  Control  System  developed  by  Vi  A,  Inc.  of 
Northfield,  Minnesota.  Both  projects  demonstrate  the  inherent  flexibility  and  risk 
reduction  of  the  rapid  prototyping  approach  to  system  design. 
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L  INTRODUCTION 


The  modern  engineer  has  a  myriad  of  new  tools  to  assist  in  the  design  and 
implementation  of  ever  increasingly  complex  control  systems.  One  promising  emerging 
technology  is  rapid  prototyping.  Rapid  prototyping  allows  the  user  to  make  the  most  of 
limited  time  whether  using  classical  or  modem  control  techniques.  By  totally  integrating 
the  development  process,  a  Rapid  Prototyping  System  (RPS)  takes  the  designer  from 
initial  concept  to  testing  on  actual  hardware  in  a  systematic,  logical  sequence.  A  RPS 
uses  the  capacity  of  the  digital  computer  to  ease  the  design  process  by  providing  a 
graphical,  interactive  environment.  The  results  are  tested  in  simulation  and  coded  in  a 
high  level  language  using  rapid  prototyping  software  tools.  The  real  power  of  the  RPS  is 
in  the  coding  ability  of  the  software  tools.  RPS  coding  allows  the  designer  to  create  a 
functional  prototype  early  in  the  development  process  and  facilitates  system  changes  and 
improvements  by  removing  the  laborious  task  of  writing  processor  code  by  hand. 
Additional  RPS  tools  allow  hardware  in  the  loop  testing  of  the  system’s  actual 
equipment. 

At  the  Naval  Postgraduate  School’s  Aeronautical  Engineering  Department  (NPS 
Aero),  we  have  applied  the  concept  of  rapid  prototyping  to  the  discipline  of  flight  control. 
Traditionally,  flight  control  systems  have  been  designed  using  classical  design  methods. 
The  advent  of  digital  flight  control  systems  and  their  associated  real-time  processors  has 
begun  to  change  this  fact.  However,  engineers  are  reluctant  to  utilize  computer  generated 
code  for  safety  critical  systems  such  as  flight  control.  It  is  our  aim  at  NPS  to  demonstrate 
that  RPS  designed  systems  are  safe  and  are  the  future  of  flight  control  design. 

Once  widely  accepted  as  safe  and  effective,  the  practice  of  rapid  prototyping 
could  revolutionize  the  flight  control  design  process.  This  is  especially  true  for 
applications  to  the  operational  flight  programs  (OFP)  of  military  aircraft.  Currently,  most 
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military  aircraft  utilize  unique  proprietary  programming  languages;  resulting  in  OFPs  that 
are  extremely  cumbersome  and  difficult  to  update.  Most  platforms  only  have  a  few 
engineers  that  have  the  knowledge  to  write  code  for  that  system.  The  incorporation  of 

rapid  prototyping  would  greatly  speed  up  the  update  process  as  well  as  greatly  decrease 
the  cost. 

The  NPS  RPS  consists  of  a  commercially  available  rapid  prototyping  software 
suite  and  open  architecture  hardware  to  permit  the  greatest  possible  range  of  control  and 
navigation  projects.  The  NPS  RPS  takes  rapid  prototyping  one  step  further  by  using  the 
software  tools  to  perform  actual  operational  flight  testing  of  the  control  systems.  The 
RPS  is  crucial  m  that  it  allows  the  Postgraduate  School’s  unique  brand  of  officer/student 
to  participate  in  projects  from  the  initial  concept  to  the  flight  testing  phases  of  the  design 
process.  This  thesis  will  describe  in  detail  two  of  these  projects;  the  development  of  an 
Airspeed  Controller  using  the  RPS  tools;  and  the  integration  of  a  Voice  Control  System 
developed  by  ViA,  Inc.  of  Northfield,  Minnesota.  Both  projects  demonstrate  the  inherent 
flexibility  and  risk  reduction  of  the  rapid  prototyping  approach  to  system  design. 
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n.  RAPID  PROTOTYPING  SYSTEM 


The  purpose  of  a  Rapid  Prototyping  System  (RPS)  is  to  aid  the  systems 
engineering  process  by  providing  a  set  of  integrated  tools  that  allow  the  engineer  to 
quickly  design,  test  and  implement  a  control  concept.  The  RPS  developed  by  the  Naval 
Postgraduate  School’s  Aero  Department  utilizes  the  MATRIXx  Product  Family  of 
software  tools  developed  by  Integrated  Systems,  Inc.  (ISI)  of  Sunnyvale,  California.  This 
software  collection  along  with  the  ground  station  and  FROG  unmanned  aerial  vehicle 
(UAV)  allow  control  projects  to  be  developed  from  initial  concept  to  final  flight  testing. 
The  iterative  system  design  process  is  greatly  accelerated  since  changes  to  the  project  do 
not  require  extensive  manual  reworking  of  the  real-time  controller  computer  code.  This 
is  very  important  in  the  NPS  academic  setting  as  it  allows  the  officer/students  to  complete 
projects  from  the  initial  design,  to  the  final  testing  phase  in  the  limited  amount  of  time 
available.  Refs.  [1-3]  provide  additional  information  about  the  RPS. 

A  SOFTWARE  TOOLS 

The  MATRIXx  Product  Family  provides  an  integrated  set  of  software  tools  for  the 
development  of  control  systems.  Figure  1  illustrates  how  the  different  MATRIXx  tools 
are  integrated  and  the  functionality  each  provides.  The  functions  of  each  component  of 
the  rapid  prototyping  software  set  are  described  below. 

1.  Realsim  GUI 

The  Realsim  Graphical  User  Interface  (GUI)  provides  overall  control  of  the 
MATRIXx  rapid  prototyping  tools.  The  GUI  (Figure  2)  is  intended  to  step  the  user 
through  the  design  process  from  initial  formulation  to  actual  real-time  implementation  of 
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the  control  system.  The  GUI  also  controls  data  acquisition  with  the  Data  Acquisition 
Editor  function  that  allows  the  recording  of  any  system  input  or  output. 


MATRIX,  Product  Faitiiry  Fiinelionalily 


Figure  1.  MATRIX,,  Product  Family  [Ref.  4] 
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Xmath/SystemBuild 


Xmath/SystemBuild  is  an  interrelated  program  set  very  similar  to  the  more 
familiar  Matlab/Simulink  products  produced  by  MathWorks  Inc.  Xmath  is  the 
computational  engine  of  the  set  and  provides  matrix  manipulation  and  many  built-in 
functions  to  aid  in  the  design  and  analysis  of  control  systems.  SystemBuild  is  a 
graphical,  interactive  program  that  uses  both  ready-made  and  user  defined  blocks  as  the 
primary  modeling  element.  SystemBuild  also  provides  extensive  simulation  services. 
The  Xmath/SystemBuild  programs  utilize  Interprocess  Communication  (IPC)  to 
synchronize  functions  and  share  data,  allowing  several  processes  to  operate 
simultaneously.  Figure  3  illustrates  the  interrelationships  between  the 
Xmath/SystemBuild  components. 


Figure  3.  Xmath/SystemBuild  Architecture  [Ref.  4] 

SystemBuild  (Figure  4)  utilizes  a  hierarchical  “SuperBlock”  concept  to  aid  in  the 
construction  and  understanding  of  control  systems.  SuperBlocks  are  made  up  of  fimction 
blocks  that  come  from  the  library  provided  with  the  SystemBuild  program;  and  of  user 
defined  blocks.  One  of  the  program’s  strengths  is  that  it  allows  the  user  to  label  and 
display  each  individual  variable.  The  connection  editor  allows  the  user  to  pass  the 
variables  up  and  down  the  hierarchical  structure  while  preserving  the  variable  names. 
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Connections  can  also  be  made  to  the  “outside  world”,  with  inputs  and  outputs  utilized  by 
the  Interactive  Animation  Editor  and/or  Hardware  Connection  Editor  described  later  in 
this  section.  SystemBuild  also  includes  a  “Transform  Block”  function  that  converts 
continuous  time  systems  to  discrete  time  systems  and  vice  versa.  Figure  4  shows  two 
equivalent  systems.  A  time  delay  must  be  added  to  the  discrete  system  to  prevent 
algebraic  loop  errors  when  code  is  generated. 

Outer  Layer  Inner  Layer 

Summer  Integrator 


Figure  4.  SystemBuild  Graphical  Design  Environment 

The  Xmath/SystemBuild  program  set  includes  an  extensive  array  of  simulation 
functions  that  allow  the  engineer  to  test  a  new  control  system  and  determine  whether  or 
not  it  meets  design  requirements.  The  use  of  these  functions  will  be  covered  in  depth  in 
Chapter  III.  SystemBuild  allows  the  user  to  save  the  system  as  a  real-time  code  file  (.rtf) 
that  IS  used  by  the  other  Realsim  components  to  generate  code  in  a  higher  level  language 


such  as  C  or  ADA.  This  code  can  be  run  on  a  real-time  processor  and  used  for  hardware 
in  the  loop  testing  or  actual  real-time  system  control. 

3.  AutoCode/Compile  and  Link 

One  of  the  most  powerful  and  time  saving  elements  of  the  MATRIXx  Product 
Family  is  AutoCode.  AutoCode,  on  the  left-hand  path  of  the  Realsim  GUI  (Figure  2), 
uses  the  .rtf  file  generated  by  SystemBuild  as  an  input  to  generate  high  level  code;  in  the 
C  programming  language  in  the  case  of  the  NPS  RPS.  In  order  to  generate  code  for  the 
proper  real-time  processor,  the  target_config.cfg  file  must  be  updated  via  the  retarget 
utility  available  in  the  Realsim  GUI.  The  lower  middle  and  right-hand  blocks  of  the 
Realsim  GUI  (Figure  2)  show  the  user  the  currently  selected  host  computer  and  target 
real-time  processor. 

Once  the  code  has  been  generated  it  is  sent  to  a  host  computer  via  the  “Compile 
and  Link”  function.  The  host  computer,  described  in  full  in  the  next  section,  also 
contains  the  real-time  processor  and  input/output  boards.  Selecting  Compile  and  Link  in 
the  Realsim  GUI  transfers  the  C  files  to  the  host  computer  via  FTP.  The  host  computer 
compiler  generates  the  object  code  and  the  link  produces  the  executable  code  for  the 
target  processor. 

4.  Interactive  Animation  Editor/Hardware  Connection  Editor/Realsim 
Drivers 

The  right-hand  side  of  the  Realsim  GUI  steps  the  engineer  through  the  design  and 
hook-up  of  the  input/output  (I/O)  interfaces  for  the  control  system.  The  Interactive 
Animation  (lA)  Editor  enables  the  user  to  design  and  build  a  graphical  interface  with  the 
control  system  that  allows  real-time  user  inputs  as  well  as  the  display  of  system  outputs 
during  testing  and  operational  use  of  the  controller.  The  connection  editor  allows  the 
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input  and  output  display  icons  to  be  connected  to  the  system  in  the  same  manner  as 
connections  are  made  in  SystemBuild.  Several  interconnected  lA  interfaces  may  be 
created  for  a  control  system.  Figure  5  shows  an  example  of  a  user  lA  interface  created 
for  the  system  pictured  in  Figure  4. 


Figure  5.  Example  lA  Interface 

The  Hardware  Connection  Editor  (HCE)  is  used  to  associate  system  inputs  and 
outputs  with  external  I/O  hardware.  Many  different  external  I/O  devices  are  available 
from  ISI  and  are  provided  complete  with  Realsim  compatible  drivers.  The  HCE  is 
configured  to  recognize  the  available  I/O  boards  and  allows  only  functions  associated 
with  those  boards  to  be  selected.  For  a  complete  explanation  of  the  HCE,  see  Ref  [4], 
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5, 


Download  and  Run 


The  final  selection  available  on  the  Realsim  GUI  is  “Download  and  Run”. 
Selecting  this  function  will  load  the  executable  code  into  the  target  processor  and  prepare 
it  for  real-time  operation.  The  lA  Client  Control  window  and  the  upper  level  user  lA 
interface  will  appear  on  the  workstation  screen  (Figure  6).  The  Client  Control  window 
enables  the  computer  operator  to  start  and  stop  the  real-time  controller.  Once  “Start 
Controller”  is  selected,  the  lA  interface  windows  are  active  and  allow  the  computer 
operator  to  input  commands  to,  and  observe  reactions  of,  the  control  system.  The  Client 
Control  window  also  allows  the  operator  to  record  the  system  variables  selected  with  the 
Data  Acquisition  Editor. 


System  Inputs 


;  System  Outputs 


5.00 


I  Dpld3ffin2,ac(^i^ 

I  Acqteddiite  Unloaded  toj  iaQj__tr8W 


>STOP 

CONTROLLER 


HOROUORE 

RESET 

<CR0TZ0ll> 


:i«R0RtfXC0  i-i '  -I .  ■i:..0C!q[UX'SXTTpH  =:::i-Pimft«ET.ERS- 


.UARIOOLE 

c'.EOlTIHe 


Figure  6 .  Real-time  Control  Windows 


B.  HARDWARE 


The  hardware  portion  of  the  RPS  is  designed  around  readily  available  commercial 
equipment  in  order  to  be  as  flexible  as  possible.  This  open  architecture  allows  for  the 
widest  spectrum  of  possible  applications  and  design  projects.  An  overview  of  the 
hardware  portion  of  the  RPS  is  provided  in  Figure  7.  Please  refer  to  it  often  as  you  read 
the  next  few  sections. 


Figure  7.  RPS  Hardware  Configuration 

1.  FROG  UAV 

The  FOG-R  flight  vehicle  (Figure  8)  was  obtained  from  the  U.  S.  Army’s 
TEXCOM  Experimentation  Center  at  Fort  Hunter  Liggett,  California.  Originally  wire 
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guided,  the  aircraft  has  been  converted  to  utilize  standard  Futaba  radio  control  equipment 
common  to  R/C  enthusiasts.  Nicknamed  the  FROG,  the  aircraft  is  a  high  wing 
monoplane  with  the  engine  mounted  on  a  pylon  atop  the  twelve  foot  span.  It  features  two 
payload  bays  that  can  hold  a  total  of  twenty  pounds  of  equipment.  The  aircraft  is 
equipped  with  an  avionics  and  sensor  suite  that  enables  it  to  be  controlled  from  the 
ground  by  computer.  This  same  suite  will  eventually  allow  for  autonomous  operation. 
The  main  components  are  described  below. 


Figure  8 .  FROG  UAV 


a.  Sensors 

The  FROG  has  a  full  pitot/static  system  consisting  of  separate  static  and 
total  pressure  sensors  located  in  the  forward  payload  bay.  These  sensors  output  analog 
voltage  signals  to  the  IMU.  These  signals  are  sampled  and  transmitted  to  the  ground 
station  as  described  below. 

Displacement  of  the  aileron  and  elevator  are  measured  by  potential  sensors 
which  output  analog  voltage  signals  to  the  IMU.  These  signals  are  sampled  and 
transmitted  to  the  ground  station  as  described  below. 

b.  Watson  Inertial  Measurement  Unit  (IMU-600AD) 

Located  in  the  center  payload  bay.  Figure  9,  the  IMU  measures  aircraft 
linear  accelerations  and  angular  rates.  It  samples  the  data  at  a  25  Hz  rate  and  outputs  it  in 
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the  digital  RS-232  format.  The  IMU  also  has  the  capability  to  sample  and  transmit  five 
additional  channels  of  data,  four  of  which  are  used  by  the  RPS.  The  first  two  channels, 
called  wordl_imu  and  word2_imu  in  the  SystemBuild  Model,  sample  the  analog  signals 
from  the  total  and  static  pressure  sensors.  Channels  three  and  four,  wordS  imu  and 
word4_imu  sample  and  output  the  signals  from  the  control  surface  displacement  potential 
sensors. 


Figure  9.  Center  Payload  Bay 


c.  Motorola  Encore  Global  Positioning  System  (GPS) 

Also  located  in  the  center  payload  bay,  the  GPS  (Figure  9)  operates  in  a 
differential  mode  utilizing  corrections  from  an  identical  GPS  located  in  the  base  station. 
The  GPS  receive  antenna  is  located  on  the  tail  boom  of  the  aircraft  just  forward  of  the 
empennage. 

d.  DGR-1 1 5  Spread  Spectrum  RF  Modems 

Digital  data  from  the  IMU  and  GPS  is  transmitted  to  the  ground  station  by 
two  spread  spectrum  modems  located  in  the  center  payload  bay  (Figure  9).  Produced  by 
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Freewave  Inc.,  they  are  capable  of  the  transmission  of  data  at  rates  of  up  to  1 16K  baud  at 
distances  up  to  twenty  miles.  Freewave  #1  normally  operates  in  a  broadcast  mode  and 
sends  the  IMU  data  down  to  the  ground  station.  Freewave  #2  both  sends  aircraft  GPS 
data  down  to  the  ground  station,  and  reeeives  GPS  differential  corrections  from  the 
ground  station  in  a  full  duplex  mode.  Both  links  operate  at  a  9600  baud  data  rate. 

2.  Ground  Station 


Due  to  the  high  replacement  cost  of  the  computing  equipment  and  the  tenuous 
nature  of  UAV  operations,  the  ground  station  concept  is  employed  to  reduce  overall  risk 
of  the  program.  The  ground  station  provides  all  the  computational  power  used  to  perform 
the  flight  management  and  data  collection  functions  of  the  RPS.  The  “portable”  ground 
station  portion  of  the  RPS,  Figure  10,  consists  of  the  three  major  components  described 
below. 


Figure  10 .  RPS  Ground  Station 


a.  SPARC  2 

The  SPARCStation  2  workstation  named  “Intrepid”  executes  all  of  the 
MATRIXx  software  tools  described  in  Section  A  of  this  chapter.  Everything  from  initial 
development,  to  the  actual  control  of  the  aircraft  during  flight  test,  is  performed  utilizing 
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this  computer.  During  both  hardware  in  the  loop  and  flight  testing,  control  inputs  to  the 
aircraft  are  entered  utilizing  lA  sereens  displayed  on  this  computer.  All  data  recording 
and  subsequent  data  analysis  is  also  performed  on  this  workstation.  In  the  interest  of 
portability  and  cost,  the  workstation  is  slated  to  be  replaced  by  a  Pentium  notebook 
computer  running  the  MATRIXx  software  tools. 

b.  Luggable  PC/ IP  Modules 

The  Luggable  PC  unit,  called  AClOO  (Figure  11),  eontains  the  host 
processor  and  the  AC- 100  Model  C30  real-time  hardware  controller.  The  host  computer 
handles  FTP,  compile,  link  and  download  functions  of  the  system  as  described  in  Section 
A  of  this  chapter.  The  C30  board  contains  a  Texas  Instruments’  TMS320C30  floating¬ 
point  DSP.  The  C30  board  works  in  conjunction  with  the  “DSP_FLEX”  board  that  can 
hold  up  to  four  I/O  boards  called  “IP”  modules.  Once  “Download  and  Run”  is  selected 
on  the  Realsim  GUI,  the  C30  DSP  executes  the  controller  code  and  provides  commands 
to  the  IP  modules  on  the  DSP_FLEX  board  and  also  to  the  lA  screens  by  a  TCP/IP 
connection  to  the  SPARC  workstation.  AClOO  contains  one  DSP  FLEX  board  with  the 
following  IP  modules  connected  to  the  C30  board  by  ribbon  cables.  Table  1  summarizes 
the  configuration  of  the  IP  modules. 


Figure  11.  AClOO  Luggable  Computer 
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(1)  IP_Serial  Module:  AC  100  contains  two  of  these 
boards.  Each  provides  two  channels,  labeled  A  and  B,  of  serial  asynchronous  or 
synchronous  communications  protocols  with  RS-232-C  and  RS-422  capability.  Serial  #1 
handles  inputs  from  the  Aircraft’s  IMU  and  the  Differential  GPS  (DGPS)  system.  Serial 
#2  is  used  in  conjunction  with  the  Voice  Control  System. 

(2)  IP_DAC  Module:  This  board  provides  six 
channels  of  digital  to  analog  conversion.  It  is  used  to  provide  flight  control  command 
voltages  to  the  modified  Futaba  RC  transmitter  described  below. 


(3)  IP_68332  Module:  This  board  has  sixteen 

channels  of  user  configurable  input  or  output.  It  is  used  to  measure  the  PWM  signals 
being  transmitted  by  the  Futaba  controllers. 


Module 

DSP_FLEX 

Input 

Output  1 

Position 

A 

B 

A 

B 

IP_Serial#l 

1 

IMURF 

Modem 

GPSRF 

Modem 

IP_Serial  #2 

3 

Voice  from 
Laptop 

Voice  to 
Laptop 

IP_DAC 

2 

Volts  to  Futaba  TX 

IP_68332 

4 

Futaba  PWM  RX 

Table  1.  AClOO  I/O  Configuration 


c.  Communications  Box/Antennas 

The  communications  box  (Figure  12)  contains  all  the  equipment  necessary 
to  send  and  receive  data  fi-om  the  FROG  UAV.  The  four  IP  boards  are  connected  to  the 
communications  box  by  50  pin  SCSI  ribbon  cables.  The  main  components  of  the  comm 
box/antenna  array  are  described  below. 
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Figure  12.  Comm  Box 

(1)  DGR-115  Spread  Spectrum  RF  Modems:  The 

communications  box  holds  two  of  these,  identical  to  the  ones  in  the  aircraft.  They 

receive  the  IMU  and  GPS  information  from  the  aircraft  and  pass  it  to  the  C30  via  the 
IP_Serial  board  #1 . 


(2)  Motorola  Encore  GPS:  Identical  to  the  GPS  in  the 
aircraft,  this  receiver  is  used  to  provide  differential  corrections  to  the  aircraft.  The 
position  of  the  ground  station  GPS  antenna  has  been  surveyed  and  is  at  a  known  latitude 
and  longitude.  Use  of  the  differential  mode  of  the  GPS  system  improves  position 
accuracy  from  on  the  order  of  10  meters  to  on  the  order  of  1  meter.  The  ground  station 
GPS  is  connected  to  the  GPS  Freewave  via  serial  cable.  For  an  in  depth  discussion  of  the 
use  of  DGPS  with  the  FROG  aircraft,  see  [Ref.  3]. 

(3)  Futaba  PWM  Receiver:  This  receiver,  identical  to 
the  one  in  the  aircraft,  is  used  to  record  the  actual  PWM  commands  being  transmitted  to 
the  FROG.  It  is  connected  to  the  IP  68332  module. 
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(4)  Modifled  Futaba  Transmitter:  A  rewired  R/C 
controller  that  takes  input  from  the  C30  via  the  IP  DAC  board  and  allows  computer 
control  of  the  UAV  with  standard  Futaba  PWM  signals.  It  is  connected  to  the  Comm 
Box  by  a  standard  9  pin  cable.  The  transmitter  is  also  connected  by  cable  to  the  UAV 
pilot’s  Futaba  transmitter  and  operates  as  a  slave  in  a  trainer  mode.  This  mode, 
developed  to  train  novice  R/C  pilots,  allows  the  slave  transmitter  to  command  the  aircraft 
only  while  the  UAV  pilot  holds  the  Trainer  Switch  engaged.  This  setup  enhances  safety 
of  flight  by  allowing  the  UAV  pilot  to  instantly  take  command  of  the  aircraft. 

(5)  Voice  Pigtail:  Provides  connection  point  for  Voice 
Control  System  detailed  in  Chapter  IV.  It  is  connected  to  the  “A”  side  of  IP  Serial  board 
#2. 

(6)  Antenna  Array:  Provides  two  helix  antennas,  one 
for  each  RF  modem,  and  a  “puck”  antenna  for  the  DGPS  station  (Figure  13).  Connected 
to  the  communication  box  by  coaxial  cables. 


Figure  13 .  Antenna  Array 
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in.  AIRSPEED  CONTROLLER 


This  chapter  details  the  design  and  implementation  of  an  airspeed  controller  for 
the  FROG  UAV  utilizing  the  RPS  discussed  in  the  previous  chapters.  The  need  for  an 
Airspeed  Controller  became  evident  during  this  voice  control  and  other  FROG  projects. 
Earlier  versions  of  the  FROG  control  algorithms  allowed  lateral  and/or  longitudinal 
control  of  the  aircraft  by  the  ground  station  in  a  manual  or  an  autonomous  mode; 
however,  the  throttle  channel,  and  thus  airspeed  control,  was  left  imder  the  control  of  the 
UAV  pilot.  In  order  to  build  a  control  system  capable  of  truly  autonomous  flight  and 
landing,  manipulation  of  all  four  of  the  basic  inputs  for  controlled  flight,  changes  in 
aileron  (5a),  elevator  (5e),  rudder  and  throttle  (6t),  is  necessaiy.  Control  of  the  first 
three  has  been  addressed  during  previous  projects.  The  success  of  this  effort  will  allow 
follow  on  projects  to  address  much  more  complicated  flight  management  problems. 

The  design  of  the  Airspeed  Controller  will  follow  the  systematic  approach  offered 
by  utilization  of  the  RPS.  First,  the  basic  problem  and  the  requirements  the  controller 
must  meet  are  identified.  Alternative  solutions  are  discussed.  Once  the  most  attractive 
solution  is  chosen,  the  basic  layout  of  the  controller  is  designed.  This  layout  is 
transferred  to  the  Xmath/SystemBuild  environment  and  the  completed  system  tested  in 
simulation.  The  controller  is  then  tested  with  hardware  in  the  loop  using  the  other 
Realsim  tools  and  finally  flight  tested.  As  stated  earlier,  the  power  of  this  approach  is 
that  the  same  real-time  code  that  performs  the  simulation,  actually  flies  the  vehicle  during 
flight  test. 

A  DESIGN  APPROACH  AND  REQUIREMENTS 

In  order  to  control  the  airspeed  of  the  FROG  vehicle  it  is  necessary  to  control  the 
throttle  movement  of  the  engine.  While  it  is  possible  to  affect  airspeed  through  elevator 
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and  to  a  lesser  degree  aileron  and  rudder  deflections,  the  most  efficient  method  is  by 
varying  throttle  position  to  maintain  desired  airspeed.  This  is  especially  true  of  the 
benign  flight  regime  in  which  the  FROG  usually  flies.  The  effect  of  the  gentle 
longitudinal  and  lateral  control  changes  on  airspeed  can  be  completely  negated  by  a 
properly  designed  Airspeed  Controller. 

1.  Control  Signal  Path 

The  throttle  in  the  FROG’s  engine  is  actuated  by  a  Futaba  servo.  Unlike  the 
control  surfaces,  the  throttle  servo  is  not  controlled  through  the  autopilot,  so  direct 
control  of  the  throttle  is  possible.  In  order  to  emulate  pilot  control,  a  feedback  controller 
that  compares  actual  aircraft  speed  as  measured  by  the  pitot/static  system  to  conunanded 
airspeed  was  chosen  as  the  design  approach.  The  path  the  control  signals  will  follow  is 
detailed  in  Figure  14.  For  our  purposes,  design  of  the  airspeed  controller  deals  with  the 
blocks  inside  the  dashed  line  and  is  implemented  using  the  rapid  prototyping  software 
tools. 


Figure  14 .  Control  Signal  Path 
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2.  Airspeed  Controller  Requirements 


Determining  just  what  performance  is  expected  from  a  controller  is  a  big  part  of 
the  design  process.  The  Airspeed  Controller  was  designed  to  meet  the  following 
requirements: 


a.  Seamless  Transitions 

Controller  should  not  cause  a  large  fluctuation  in  throttle  movement  when 
initially  selected  or  deselected. 

b.  Zero  Steady  State  Error 

Controller  should  achieve  zero  steady  state  tracking  error  in  airspeed  in 
the  presence  of  constant  and  light  variable  winds. 

c.  Bandwidth 

The  bandwidths  for  the  throttle  channel  should  be  wide  enough  for  tight 
tracking  of  airspeed,  but  narrow  enough  to  prevent  throttle  controller  from  causing  engine 
stalls. 


d.  Stability  Margins 

Gain  and  Phase  Margins  for  each  loop  should  be  greater  than  6  dB  and  45° 

respectively. 

B.  DESIGNING  THE  CONTROLLER  IN  THE  XMATH/SYSTEMBUILD 
ENVIRONMENT 

The  main  effort  of  this  project  was  to  design  the  Airspeed  Controller  block 
depicted  in  Figure  14.  The  other  blocks  that  complete  the  overall  controller 
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implementation  are  mainly  for  the  conversion  of  inputs  or  outputs  into  quantities  that  are 
in  the  proper  form  for  the  controller,  in  the  case  of  inputs,  or  the  hardware,  in  the  case  of 
outputs,  to  utilize. 

1.  FROG  Controller  Overview 

The  FROG  UAV  control  system  is  quite  complicated.  The  system  provides  a 
myriad  of  flight  management  services  including  navigation  and  flight  control.  The  upper 
layer  of  the  SystemBuild  model  (Figure  15)  details  the  external  inputs  and  outputs  to  the 
flight  management  system.  As  specified  earlier,  the  inputs  come  from  either  the  IP  I/O 
modules  or  are  entered  via  lA  interface  windows.  Outputs  are  either  sent  to  an  IP  module 
or  displayed  on  lA  interface  windows. 


Figure  15 .  Upper  Level  of  FROG  Control  Model 


Inside  the  Flight  Management  SuperBlock  (Figure  16)  reside  the  SuperBlocks  that 
perform  the  main  services  of  the  flight  management  system. 


Figure  16.  Flight  Management  SuperBlock 


2.  Throttle  Control  SuperBlock  Overview 

The  Throttle  Control  SuperBlock,  located  inside  the  Control  SuperBlock,  consists 
of  three  main  parts:  a  block  that  freezes  the  value  of  certain  variables  when  various 
switches  are  engaged;  an  open  loop  controller  and  a  closed  loop  controller.  The  operator 
selectable  open  loop/closed  loop  (OL/CL)  switch  allows  the  choice  of  either  as  the 
primary  Airspeed  Controller.  A  limiter  prevents  the  output  of  either  controller  from 
commanding  airspeeds  less  than  stall  or  greater  than  V^ax-  The  implementation  of  the 
upper  level  blocks  of  the  Airspeed  Controller  are  depicted  in  Figure  1 7. 

3.  Current  Conditions  Hold  SuperBlock 

The  first  component  of  this  SuperBlock  (Figure  1 8),  records  the  value  of  PWM 
being  transmitted  to  the  throttle  by  the  UAV  pilot’s  controller  at  the  moment  the  Trainer 
Switch  is  selected.  The  frozen  PWM  value  is  used  as  a  reference  by  the  Open  Loop 
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Controller  for  all  commanded  speed  changes  during  that  run.  The  second  block  records 
the  value  of  airspeed  at  the  moment  the  OL/CL  switch  is  selected  “ON”.  This  value  is 
used  as  a  reference  by  the  Closed  Loop  Controller.  The  BlockScript  code  for  these  user 
defined  blocks  is  detailed  in  Appendix  A. 


Figure  17.  Throttle  Control  SuperBlock 


Figure  18.  Current  Conditions  Hold  SuperBlock 

4.  Open  Loop  Controller 

The  Open  Loop  Controller  (Figure  19)  provides  airspeed  control  by  directly 
manipulating  the  throttle  position.  At  transition  to  computer  control,  the  Current 
Conditions  Hold  SuperBlock  provides  a  reference  PWM  to  the  Open  Loop  Controller 
which  is  used  as  the  initial  commanded  PWM.  This  provides  for  a  seamless  transition 


assuming  that  initially  the  change  commanded  from  the  I A  page  (APWM)  is  set  to  zero. 
The  commanded  PWM,  and  thus  airspeed,  is  increased  or  decreased  by  adjusting  the 
APWM.  The  rate  at  which  APWM  can  change  is  controlled  by  the  limited  integrator 
feedback  loop.  This  rate  can  be  adjusted  utilizing  the  variable  acceleration  gain.  It  is 
important  to  limit  the  maximum  rate  of  throttle  movement  in  order  to  prevent  the 
controller  from  causing  an  engine  stall  while  airborne.  The  maximum  safe  value  of  the 
acceleration  gain  will  be  determined  during  the  hardware  in  the  loop  testing  phase. 

User  control  of  APWM  and  the  acceleration  gain  is  provided  through  the  Throttle 
Control  lA  window  described  below.  The  commanded  PWM  is  converted  to  open  loop 
velocity  commanded  using  the  same  inputs  for  slope  and  intercept  as  the  Conv  to  PWM 
SuperBlock  detailed  later  in  this  section.  The  controller  outputs  open  loop  velocity 
commanded  directly  to  the  OL/CL  Switch.  With  the  switch  in  the  “OFF”  position,  the 
open  loop  velocity  commanded  becomes  the  velocity  commanded. 


Figure  19.  Open  Loop  Controller  Configuration 


5.  Closed  Loop  Controller 

Unlike  the  Open  Loop  Controller,  the  Closed  Loop  Controller  (Figure  20)  utilizes 
a  feedback  loop  that  compares  commanded  velocity  to  actual  aircraft  speed.  Think  of  it 
as  cruise  control  for  the  FROG.  In  order  to  meet  the  requirements  specified  in  section  A- 
2  of  this  chapter,  a  feedback  Proportional/Integral  (PI)  controller  was  chosen.  The 
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Closed  Loop  Controller  produces  a  velocity  commanded  signal  and  uses  the  actual 
aircraft  speed  as  measured  by  the  pitot  system  as  the  feedback  signal. 


Figure  20.  Closed  Loop  Controller  Configuration 


The  Closed  Loop  Controller  initially  commands  the  velocity  captured  by  the 
Current  Conditions  Hold  SuperBlock  at  the  time  of  selection  of  the  OL/CL  switch  to  the 
“ON”  position.  This  provides  for  a  fairly  seamless  transition  depending  on  wind 
velocity.  The  user  increases  or  decreases  the  selected  speed  by  adjusting  the  rate  limited 
AV  value  as  described  below.  The  held  velocity  and  commanded  delta  are  added  to 
produce  the  user  commanded  velocity  input  which  is  displayed  on  the  Throttle  lA  page. 
The  actual  aircraft  speed  is  subtracted  fi'om  this  value  to  create  the  error  signal  on  which 
the  controller  acts.  The  controller  used  was  a  basic  PI  controller,  where  the  proportional 
gam,  Kp,  was  set  to  one;  and  the  integral  gain,  Ki,  to  one  as  well.  The  output  is  sent 
through  a  variable  throttle  gain  that  allows  the  operator  to  control  the  reaction  time  of  the 
controller.  A  limited  integrator  is  used  to  control  the  magnitude  of  the  velocity 
commanded.  The  50  knot  bound  is  large  enough  to  allow  the  entire  range  of  airspeeds 
which  the  FROG  is  capable  of  obtaining  to  be  commanded. 


The  two  switches  are  part  of  the  Wind  Down  Loop.  If  either  or  both  switches  are 
in  the  “OFF”  position,  the  integrator  is  forced  back  to  its  initial  value.  This  is  done  to 
prevent  initiation  of  the  closed  loop  controller  at  a  previous  state.  The  error  signal  is 
added  to  the  reference  velocity  provided  by  the  Current  Conditions  Hold  SuperBlock. 
The  output  of  the  Closed  Loop  Controller  is  sent  to  the  OL/CL  switch  and  becomes  the 
velocity  commanded  when  the  switch  is  selected  to  the  “ON”  position. 

6.  Control  Loop  Analysis 

In  order  determine  if  the  controller  meets  the  bandwidth  and  stability  margin 
requirements,  the  feedback  system  must  be  “broken”  at  control  and  sensor  loops.  The 
first  look  is  at  the  control  loop  as  pictured  in  Figure  21.  The  system  was  linearized  and  a 
Bode  plot  generated  using  the  appropriate  Xmath  functions.  Figure  22  is  the  Bode 
representation  of  the  control  loop  and  shows  a  gain  margin  of  12  dB,  which  meets  the 
design  requirement  of  6  dB.  Unfortunately  it  also  shows  a  phase  margin  of  22°  which  is 
below  the  45°  requirement  detailed  earlier.  Further  testing  showed  that  a  Throttle  Gain  of 
.3  produced  the  required  phase  margin,  but  unacceptably  sluggish  performance.  It  was 
decided  to  leave  the  Throttle  Gain  at  one  and  accept  the  reduced  phase  margin. 

Figure  22  also  shows  a  bandwidth  of  .35  radians  per  second  (rad/sec).  This  is  not 
surprising  since  the  CL  Controller  was  designed  to  operate  a  low  frequencies  in  order  not 
to  cause  engine  stalls  by  moving  the  throttle  too  quickly. 

7.  Sensor  Loop  Analysis 

The  sensor  loop  analysis  (Figure  23)  produced  results  very  similar  to  the  control 
loop.  Figure  24  shows  the  sensor  loop  produces  the  same  gain  and  phase  margins  as  well 
as  bandwidth.  The  gain  margin  and  bandwidth  requirements  are  met  and  give  adequate 
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Figure  23 .  Sensor  Loop 
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Figure  24.  Sensor  Loop  Bode  Plot 


29 


8. 


State  Analysis 


Whenever  one  designs  a  control  system  it  is  important  to  analyze  the  effects  of  all 
the  possible  states  of  that  system.  The  Airspeed  Controller,  with  its  two  switches,  has  a 

total  of  four  possible  states.  The  states  and  resulting  actions  of  the  controller  are 
summarized  in  Table  2. 


State 

TR  Switch 

Position 

OL/CL  Switch 

Position 

Throttle  CMD 

Source 

0 

OFF 

OFF 

Pilot’s  TX 

I 

OFF 

ON 

Pilot’s  TX 

2 

ON 

OFF 

OL  Controller 

3 

ON 

ON 

CL  Controller 

Table  2 .  Airspeed  Controller  State  Analysis 


C  AIRSPEED  CONTROLLER  IMPLEMENTATION 

Once  the  basic  Airspeed  Controller  design  was  finalized,  it  was  integrated  into  the 
FROG  Flight  Management  SystemBuild  model.  In  order  to  accomplish  this,  several 
additional  SuperBlocks  that  convert  inputs  or  outputs  into  quantities  that  are  in  the  proper 

form  for  the  controller,  in  the  case  of  inputs,  or  the  hardware,  in  the  case  of  outputs,  to 
utilize  were  added. 

1.  Volts  to  Airspeed  Conversion 

The  Airspeed  Conversions  SuperBlock  (Figure  25)  is  located  inside  the  Calibrate 
Sensors  SuperBlock  of  the  FROG  SystemBuild  model.  The  external  input  wordljmu, 
the  sampled  voltage  output  of  the  aircraft’s  pitot  system,  is  converted  to  indicated 
airspeed  in  nautical  miles  per  hour  (knots).  Additionally,  GPS  measured  velocity  is 
converted  from  meters  per  second  to  knots.  Knots  are  used  because  this  measure  of 
vehicle  speed  is  most  familiar  to  the  officer/students  involved  in  the  various  RPS 
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projects.  The  6th  order  conversion  approximation  from  volts  to  airspeed  was  obtained  by 
Evangelos  Papageorgiou  during  his  development  of  a  dynamic  model  of  the  FROG  UAV 
[Ref  5],  The  output  of  this  block  is  the  pitot  velocity  input  to  the  Current  Conditions 
Hold  SuperBlock  and  is  also  used  as  the  feedback  signal  in  the  Closed  Loop  Controller. 
Both  pitot  velocity  and  GPS  velocity  are  displayed  on  the  Throttle  Command  lA  page 
and  recorded  for  further  analysis. 


Figure  25.  Airspeed  Conversions  SuperBlock 

Due  to  the  excessive  noise  associated  with  the  pitot  sensor,  smoothing  of  the 
wordl_imu  data  is  necessary  before  conversion  to  airspeed.  Wordl  imu  data  recorded 
during  a  previous  flight  test  (Figure  26A)  was  used  to  design  the  smoothing  filter.  A  FFT 
was  performed  on  the  data  in  Xmath  to  determine  the  frequency  content  of  the  signal  to 
pin  point  the  noise  contribution.  A  state  space  representation  of  a  lowpass  filter  was 
loaded  into  SystemBuild  and  a  simulation  performed  using  the  actual  pitot  sensor  data  as 
input.  By  trail  and  error,  a  filter  with  the  following  transfer  fimction  was  determined  to 
be  sufficient  to  provide  the  required  suppression  of  the  high  frequency  noise: 
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Figure  26B  illustrates  the  smoothing  effect  the  filter  has  on  the  wordl_imu  input 
signal.  The  output  of  the  Airspeed  Conversions  SuperBlock,  aircraft  velocity  measured 
in  knots,  is  shown  in  Figure  26C. 


Figure  26.  Airspeed  Filtering 


2.  Airspeed  to  PWM  Conversion 

The  velocity  commanded  output  from  the  Throttle  Control  SuperBlock,  whether 
open  loop  or  closed  loop,  must  be  converted  into  a  form  that  can  be  used  by  the  hardware 
portion  of  the  RPS.  As  explained  in  an  earlier  section,  the  aircraft  accepts  PWM  control 
signals  from  the  computer  via  a  modified  Futaba  transmitter  that  accepts  a  voltage  signal 
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supplied  by  the  C30/IP_DAC  as  an  input.  Earlier  projects  that  addressed  control  of  the 
elevator  and  ailerons  also  faced  this  problem  [Ref.  2].  The  conversion  from  velocity 
commanded  to  throttle  voltage  commanded  is  performed  using  a  two  step  process.  Both 
conversions  occur  within  the  Calibrate  Uplink  SuperBlock.  The  first  step  is  to  convert  the 
velocity  commanded  to  PWM  commanded.  This  is  done  by  the  Conv  to  PWM 
SuperBlock;  a  portion  of  which  is  illustrated  in  Figure  27.  The  conversion  to  PWM  is  a 
linear  approximation,  the  parameters  of  which  are  entered  by  the  user  in  an  lA  interface, 
the  applicable  part  of  which  is  also  depicted  in  Figure  27.  The  values  entered  for  the 
conversion  were  determined  by  analyzing  data  from  several  flight  tests;  comparing  steady 
state  velocity  as  measured  by  the  aircraft’s  pitot/static  system  to  controller  PWM 
commanded.  The  output  is  passed  through  a  limiter  to  prevent  the  controller  from 
commanding  a  PWM  that  is  to  high  or  low  for  safe  flight. 


Figure  27.  Knots  to  PWM  Conversion 


3.  PWM  to  Volts  Conversion 

The  PWM  to  Volts  SuperBlock  completes  the  conversion  of  commanded  airspeed 
to  volts.  Also  located  inside  the  Calibrate  Uplink  SuperBlock,  this  block  uses  a  linear 
approximation  to  convert  PWM  to  Volts  (Figure  28).  This  conversion  is  obtained  prior  to 
each  flight  during  a  calibration  process  using  the  Calibrate  DAC  lA  interface  window. 
With  the  Trainer  and  Cal  Mode  Switches  engaged,  the  commanded  voltage  on  the  dial 
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input  shown  in  Figure  28  is  sent  directly  to  the  modified  Futaba  transmitter  where  it  is 
transmitted  as  a  PWM  command.  The  ground  station  Futaba  receiver  receives  this 
command  and  it  is  sent  to  the  lA  window  via  the  IP_68332  board.  The  user  sets  the 
PWM  values  for  2.4  and  2.7  volts  commanded  into  the  sliders  on  the  lA  interface  and  the 
calibration  is  complete.  The  process  for  converting  the  velocity  commanded  signal  to  a 
volts  commanded  signal  is  now  finished.  Once  converted,  the  throttle  voltage 
commanded  is  sent  to  the  modified  Futaba  transmitter  through  the  IP  DAC  module. 


Figure  28.  PWM  to  Volts  Conversion 


4.  User  Interface 

Now  that  an  Airspeed  Controller  has  been  realized  in  the  SystemBuild 
environment,  a  means  to  provide  inputs  to  the  controller  and  observe  its  operation  must 
be  created.  As  described  earlier,  the  MATRIXx  Product  Family  provides  an  extremely 
powerful  tool  for  creating  interactive  interfaces  with  SystemBuild  control  models.  The 
Airspeed  Controller  lA  window  or  Throttle  Control  page  is  shown  in  Figure  29. 

This  page  was  created  specifically  for  flight  testing  and  displays  many  values 
neither  desired  or  required  on  an  operational  flight  display.  The  right  side  of  the  display 
contains  the  user  input  to  the  Airspeed  Controller.  This  includes  the  input  deltas  in  PWM 
(OL)  and  knots  (CL),  the  CL  airspeed  input  display,  the  acceleration  and  throttle  gains, 
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and  the  OL/CL  Switch.  Also  displayed  is  the  airspeed  of  the  aircraft  as  measured  by  both 
the  GPS  and  pitot/static  systems.  Once  testing  is  complete,  these  controls  and  indications 
will  be  incorporated  onto  the  main  flight  display  page.  The  left  side  of  the  lA  window 
displays  several  values  that  will  be  indispensable  in  determining  whether  or  not  the 
controller  is  performing  correctly  during  hardware  in  the  loop  and  flight  testing.  These 
values  include  the  velocity  and  PWM  values  held;  controller  and  actual  Futaba 
commanded  PWM;  and  the  commanded  speed  of  each  controller.  By  observing  and 
comparing  certain  values,  great  insight  into  controller  operation  can  be  obtained.  For 
example,  the  controller  and  actual  Futaba  transmitter  PWM  commands  would  be  equal  if 
the  conversion  blocks  inside  the  SystemBuild  models  were  exact.  By  analyzing  these 
values,  the  user  can  make  a  judgment  about  the  quality  of  the  system  calibration. 
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Figure  29.  Airspeed  Controller  lA  Interface  Page 
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D.  SIMULATION  AND  TESTING  IN  THE  XMATH/SYSTEMBUILD 
ENVIRONMENT 

The  MATRIXx  Product  Family  provides  extensive  simulation  and  analysis  tools 
m  the  Xmath/SystemBuild  design  environment.  These  tools  can  be  used  to  determine 
whether  or  not  a  controller  design  meets  the  performance  requirements  the  engineer  set 
out  to  fulfill.  Several  tests  were  performed  on  the  Airspeed  Controller  to  ensure  that  each 
of  the  requirements  defined  earlier  were  satisfied  by  this  design.  For  all  tests,  a 
SystemBuild  model  of  the  FROG  aircraft  and  autopilot  system  developed  by  Professor 
Isaac  Kaminer  was  used.  This  simulation  models  the  FROG  UAV  in  trimmed  flight  at  88 
feet  per  sec  (ft/s).  The  Airspeed  Controller  was  integrated  into  the  simulation. 

1.  Simulation  Runs 

The  requirements  for  seamless  transitions  and  zero  tracking  error  in  steady  state 
were  investigated  by  operating  the  controller  in  simulation.  The  Airspeed 
Controller/FROG  model  system  were  configured  as  shown  in  Figure  30.  All  Airspeed 
Controller  inputs  normally  provided  from  the  lA  screen  were  configured  to  accept  the 
output  from  SystemBuild  blocks.  The  parameters  entered  into  these  blocks  were  changed 
to  produce  the  desired  simulation.  The  SystemBuild  simulation  window  was  set  to  record 
and  graph  the  values  of  FROG  Velocity,  OL  Controller  Velocity  Commanded,  CL 
Velocity  Inputted,  CL  Controller  Velocity  Commanded  and  Controller  Velocity 
Commanded.  Figure  30  represents  a  configuration  with  a  10  feet  per  second  (ft/s) 
headwind  and  a  .2  second  actuator  delay  added  to  the  simulation  to  explore  the 
disturbance  rejection  and  robustness  of  the  controller.  The  first  set  of  runs  were 
performed  without  the  delay  and  with  the  wind  block  disconnected.  The  results  of  all  of 
the  simulation  runs  are  presented  in  Appendix  B.  For  all  runs,  the  Trainer  Switch  was 
engaged  at  the  20  second  point;  allowing  the  system  to  get  “airborne”  and  settle  into 
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steady  state  before  the  controller  was  tested.  The  OL/CL  Switch  was  engaged  at  the  30 
second  point.  For  all  test  results  the  top  graph  represents  the  reaction  of  the  FROG’s 
airspeed  to  the  controller  commands;  the  second  graph  is  the  output  of  the  OL  Controller; 
the  third  graph  is  the  inputted  CL  speed  that  the  CL  Controller  is  trying  to  maintain;  the 
fourth  graph  is  the  output  of  the  CL  Controller;  and  the  bottom  graph  is  the  limited  output 
of  the  Throttle  Control  SuperBlock.  Figure  31  details  the  results  of  three  of  these  runs 
and  clearly  shows  that  the  CL  Controller  does  indeed  meet  the  seamless  transition  and 
zero  steady  state  error  requirements. 


Figure  30.  Simulation  Setup 
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Figure  31.  Simulation  Results 

For  all  three  runs  in  Figure  31 ,  the  Trainer  Switch  was  engaged  at  20  seconds  and 
the  OL/CL  Switch  at  30  seconds.  The  commanded  velocity  was  held  constant  until  the 
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35  second  point  when  it  was  increased  by  five  knots.  In  all  three  cases  the  CL  Controller 
reacts  properly  and  drives  the  aircraft’s  airspeed  to  the  user  commanded  velocity  and 
holds  it  there. 

E.  HARDWARE  IN  THE  LOOP  TESTING 

Hardware  in  the  loop  testing  of  the  Airspeed  Controller  was  performed  using  the 
actual  FROG  UAV.  The  tests  were  performed  at  the  NPS  Aero  Department’s  Laboratory 
facilities  located  on  the  grounds  of  the  Navy  Golf  Course.  The  facilities  include  the  UAV 
Lab  where  both  testing  and  routine  maintenance  of  the  NPS  Aero  Department’s  fleet  of 
unmaimed  aerial  flight  vehicles  takes  place;  and  the  Blockhouse,  where  all  tests  and 
maintenance  requiring  the  engine  to  be  running  take  place.  For  the  hardware  in  the  loop 
testing,  the  base  station  equipment  was  set  up  in  the  engine  test  Blockhouse  as  it  would 
be  out  at  the  airfield  for  a  flight  test.  The  FROG  UAV  was  secured  just  outside  the 
Blockhouses’  open  garage  style  doors.  It  is  important  to  note  that  this  was  not  true 
hardware  in  the  loop  testing  since  we  did  not  measure  the  actual  throttle  movement;  but 
rather  the  PWM  commanded.  The  first  step  was  to  calibrate  the  throttle  in  PWM  vs. 
volts.  The  controller  was  started  and  the  CAL  DAC  lA  page  selected.  To  enable  the 
calibration  mode,  both  the  Trainer  Switch  and  the  Cal  Switch  must  be  selected  to  the  ON 
position.  The  one  difference  in  throttle  calibration  is  that  because  the  throttle  does  not 
use  the  autopilot,  the  PWM  commanded  by  the  pilot’s  controller  at  selection  of  the 
Trainer  Switch  affects  the  calibration  values.  In  order  to  circumvent  this  problem, 
throttle  calibration  is  always  initiated  with  the  pilot  commanding  1650  PWM,  the 
approximate  value  that  will  be  commanded  by  the  pilot  at  control  transition. 

In  order  to  provide  an  airspeed  indication  for  the  Airspeed  Controller,  a 
differential  pressure  imit  nicknamed  the  “Schmidter”  was  connected  to  the  pitot  probe  of 
the  aircraft.  With  the  controller  rumiing  on  the  base  station,  the  pressure  supplied  by  the 
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Schmidter  was  increased  until  the  airspeed  indieated  50  knots  on  the  I A  sereen  readout. 
With  the  engine  running,  the  UAV  pilot  selected  the  Trainer  Switch,  passing  control  of 
the  throttle  to  the  eomputer  operator.  The  Open  Loop  Controller  was  tested  by  selecting 
several  different  values  for  the  APWM  input  and  observing  reaction  of  the  engine  throttle 
and  RPM.  The  aeceleration  gain  was  raised  and  throttle  slams  (rapidly  advancing  the 
throttle  form  minimum  to  maximum  and  vice  versa)  were  performed  to  determine  the 
maximum  safe  rate  of  throttle  moverhent.  This  test  is  important  to  prevent  the  Airspeed 
Controller  from  causing  an  engine  stall  airborne. 

Testing  continued  with  the  selection  of  the  Closed  Loop  Controller.  With  the 
Schmidter  providing  a  constant  apparent  airspeed  of  50  knots,  the  throttle  eontroller 
either  drove  the  throttle  to  the  maximum,  if  the  commanded  airspeed  was  above  50  knots, 
or  the  minimum,  if  the  commanded  airspeed  was  below  50  knots.  The  controller  was 
also  tested  by  commanding  50  knots  and  varying  the  pressure  supplied  to  the  pitot  tube 
by  adjusting  the  Schmidter.  In  each  case,  the  Closed  Loop  Controller  performed  as 
expected,  driving  the  throttle  to  one  limit  or  the  other.  The  controller  gain  was  increased, 
again  to  determine  the  maximum  safe  rate  of  throttle  movement.  Before  returning  eontrol 
to  the  OL  controller,  the  inputted  airspeed  delta  was  set  to  zero.  This  was  done  to  prevent 
a  jump  in  throttle  position  during  the  transition  from  CL  to  OL  control.  The  same 
procedure  is  followed  when  returning  control  to  the  UAV  pilot.  A  test  was  performed  to 
determine  the  effect  of  mismatched  PWM  during  computer  to  pilot  transition,  in  case  it 
was  necessary  for  the  pilot  to  unexpectedly  resume  control  during  the  flight  test.  It  was 
determined  that  the  mismatch  and  resulting  PWM  jump  would  not  cause  an  engine  stall. 

The  hardware  in  the  loop  testing  was  invaluable  in  determining  that  the  Airspeed 
Controller  was  operating  properly,  and  just  as  importantly,  that  it  was  safe  to  flight  test. 
A  value  of  5  for  the  OL  acceleration  gain  and  a  value  of  1  for  the  CL  throttle  gain 
resulted  in  a  good  performance  with  no  engine  stalls.  Hardware  in  the  loop  testing  also 
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gave  the  UAV  pilot  and  computer  operator  a  chance  to  practice  and  coordinate  control 
transfers.  A  major  advantage  of  the  RPS  was  evident,  namely  that  the  exact  equipment 
and  code  utilized  for  the  hardware  in  the  loop  testing  would  perform  the  flight  test. 

F.  FLIGHT  TESTING 

Flight  testing  of  the  Airspeed  Controller  on  the  FROG  UAV  was  conducted  at  the 
Salinas  R/C  Modelers  Club  airfield  located  near  Chualar,  California.  The  airfield 
features  a  300’  asphalt  strip  positioned  in  a  north/south  orientation.  The  entire  RPS  was 
packed  up,  moved  and  reassembled  in  accordance  with  the  procedures  in  Appendix  C. 
For  the  test  flights,  the  pilot’s  Futaba  controller  was  programmed  to  relinquish  control  of 
the  throttle  channel  only  with  selection  of  the  Trainer  Switch.  The  pilot  was  instructed  to 
fly  a  race  track  pattern  while  the  airspeed  was  under  control  of  the  real-time  processor. 
The  Data  Acquisition  Editor  was  set  up  to  record  the  same  variables  that  were  recorded 
during  simulation  with  the  addition  of  the  Trainer  and  OL/CL  Switch  positions  and  PWM 
transmitted. 

The  weather  conditions  were  good  with  the  exception  of  a  strong  northerly  wind. 
A  plot  of  the  aircraft’s  indicated  airspeed  (IAS)  as  measured  by  the  pitot  system  and  the 
ground  speed  (GS)  as  measured  by  the  GPS  (Figure  32)  shows  a  wind  varying  between 
fifteen  and  twenty  knots  at  the  test  altitude. 

1.  Transition  Tests  Results 

Two  four  minute  test  nms  were  performed  and  recorded.  The  first  item  tested 
was  the  seamlessness  of  the  transitions  between  pilot  and  OL  control;  and  between  OL 
and  CL  control.  From  the  ground  the  pilot/OL  transition  was  not  detectable  by  listening 
to  the  engine.  The  transition  from  OL  to  CL  was  accompanied  by  a  detectable  throttle 
movement;  although,  not  a  drastic  one.  This  is  to  be  expected,  especially  on  a  windy  day. 
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Figure  32.  lAS/GS  Comparison 

due  to  the  fact  that  airspeed  and  not  PWM  is  captured  and  used  to  produce  the  initial 
controller  command.  Figure  33  details  the  actual  magnitude  of  the  PWM  jumps  for  test 
Run  #1 .  In  all  cases  the  engine  responded  to  the  throttle  commands  without  hesitation. 

2.  Airspeed  Traeking  Tests  Results 

The  mam  point  of  the  flight  test  was  to  determine  how  well  the  Airspeed 
Controller  tracks  commanded  speed  inputs.  Once  the  CL  Controller  was  selected,  the 
aircraft  s  reaction  to  speed  inputs  was  observed  and  recorded.  From  the  ground  station,  it 
appeared  the  controller  did  a  good  job  keeping  the  aircraft  at  the  desired  airspeed  despite 
the  windy  conditions.  Figure  34  details  the  results  of  test  Run  #1.  As  designed,  the 
Closed  Loop  Controller  freezes  the  current  aircraft  speed  at  the  selection  of  the  OL/CL 
Switch  to  the  “ON”  position.  The  initial  commanded  input  speed  is  67  knots.  The 
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controller  attempted  to  hold  this  speed  as  the  FROG  flew  in  a  circle,  turning  the 
headwind  into  a  tailwind  and  back  again.  At  the  70  second  point,  the  commanded 
airspeed  was  reduced  by  five  knots  to  62  knots  via  the  Throttle  Control  lA  page.  The 
Airspeed  Controller  reacted  properly  by  reducing  aircraft  speed.  The  controller 
responded  correctly  to  all  further  commands  during  this  run. 

The  results  of  the  Run  #2  (Figure  35)  confirm  the  findings  of  Run  #1.  However, 
this  run  highlights  one  of  the  shortcomings  of  the  FROG.  During  the  period  between  80 
and  120  seconds,  the  aircraft  was  flying  downwind  with  a  18  knot  tailwind  and  despite 
the  fact  the  controller  was  commanding  full  throttle,  the  aircraft  could  not  attain  the 
commanded  indicated  airspeed  of  77  knots.  This  is  not  a  fault  in  the  controller  design; 
but  rather,  a  result  of  the  limited  performance  of  the  FROG  aircraft  with  respect  to  the 
range  of  airspeeds  it  is  able  to  achieve. 
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MrspeeJt  (knots) 


Figure  34.  Run  #1 


Figure  35.  Run  #2 


3.  Summary  of  Flight  Testing 


The  Airspeed  Controller  design  proved  to  be  very  successful  at  maintaining  a 
commanded  aircraft  speed.  The  controller  showed  good  disturbance  (wind)  rejection  up 
to  the  limits  of  the  aircraft.  The  design  demonstrated  good  transition  qualities  between 
states.  With  the  values  for  acceleration  and  throttle  gains  determined  during  hardware  in 
the  loop  testing,  the  design  exhibited  smooth  yet  quick  control  of  throttle  movement  at 
rates  that  did  not  cause  any  adverse  affects  to  engine  performance. 

It  was  determined  that  the  input  to  the  Open  Loop  Controller  should  be  changed 
to  accept  a  AV  vice  a  APWM.  This  change  was  implemented  and  successfully  tested  on  a 

later  flight.  It  also  permits  the  controller  to  be  used  as  the  inner  loop  on  a  more  complex 
trajectory  management  system. 
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IV.  VOICE  CONTROL 


A.  BACKGROUND 

The  NPS  Aero  Department  got  involved  in  the  Voice  Control  Project  through  the 
Navy’s  Maritime  Avionics  Subsystem  Technology  (MAST)  Program.  After  a 
presentation  on  the  capabilities  of  the  ViA  Wearable  Computer  system  and  voice 
recognition  software,  Professor  Isaac  Kaminer  offered  the  FROG  UAV  as  a  possible 
candidate  for  integration  with  that  system.  The  project  proposed  that  the  ViA  system  be 
used  to  control  the  FROG  in  flight.  During  FY  98,  a  Cooperative  Research  and 
Development  Agreement  (CRADA)  was  reached  between  ViA  and  NPS. 

B.  VOICE  CONTROL  HARDWARE  AND  SOFTWARE 

The  Voice  Control  System  (VCS)  is  comprised  principally  of  commercially 
available  components.  In  addition  to  the  standard  RPS,  the  VCS  requires  the  use  of  a 
laptop  computer  to  translate  commands  between  the  ViA  Wearable  and  the  Sun 
workstation.  The  VCS  software  programs  that  run  on  the  laptop  and  wearable  computers 
are  the  only  custom  made  components  of  the  system.  Figure  36  provides  an  overview  of 
the  RPS  including  the  additional  equipment  associated  with  the  VCS. 

1.  Interfacing  with  the  RPS 

In  order  to  allow  an  external  computer  access  to  the  RPS  real-time  controller,  a 
method  for  communication  between  the  ViA  Wearable  and  the  Realsim  software  running 
on  the  Srm  workstation  was  necessary.  The  solution  selected  involved  connecting  a 
standard  laptop  computer  running  special  software  to  an  I/O  module  on  the  DSP  FLEX 
board. 
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ViA  Wearable 


Figure  36.  VCS  Oveirview 

The  original  version  of  the  software  that  allowed  commands  to  be  entered  via  the 
laptop  was  written  by  Luis  Sebastian,  a  visiting  student  from  Portugal.  His  program  is 
called  PC-serial-C30  (PC_S_C30)  [Ref  6].  The  program  requires  that  the  laptop  be 
connected  to  the  “A”  side  of  the  IP_Seriat  #2  module  via  a  null  modem  serial  cable. 
PC_S_C30  runs  under  Windows  95  and  uses  a  fiill  duplex  serial  link.  Lateral  (aileron) 
and  longitudinal  (elevator)  commands  from  the  laptop  are  sent  via  into  the  IP  Serial 
module  for  use  by  the  standard  FROG  controllers  running  on  the  C30  real-time  processor. 

Trainer  Switch  status,  GPS  local  tangent  plane  (LTP)  position 
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information  and  10  user  assignable  float  variables  for  display  on  the  program  window. 
The  controls  provided  by  PC_S_C30  are  summarized  in  Table  3.  The  basic  program  was 
tested  in  July  1997  and  was  successful  in  controlling  the  FROG  aircraft  from  the  laptop 
keyboard. 


KEY 

COMMAND 

t 

Climb 

i 

Descend 

Right  Turn 

<r- 

Left  Turn 

L 

Level  (Constant  Altitude) 

C 

Center  (Constant  Heading) 

Space 

Level  &  Center 

Q 

Standard  Turn  Rate 

A 

Half  Turn  Rate 

W 

Standard  Climb  Rate 

S 

Half  Climb  Rate 

Table  3 .  Laptop  Control  Keys 


In  order  to  allow  the  ViA  Wearable  Computer  to  interface  with  the  RPS,  the  basic 
PC_S_C30  program  was  modified  by  Jennifer  Wightman  of  ViA.  The  wearable 
communicates  with  the  laptop  by  way  of  a  Netware  Wireless  LAN  card  inserted  into  one 
of  the  PCMCIA  (PC  card)  slots  of  the  laptop.  The  Windows  95  display  of  the  current 
version  of  PC_S_C30  is  shown  in  Figure  37. 

On  the  workstation  side  of  the  connection  with  the  laptop,  an  lA  interface  screen 
was  created  to  allow  the  user  to  monitor  the  commands  received  by  the  FROG  flight 
management  program.  This  lA  page  is  illustrated  in  Figure  38.  Besides  displaying  the 
direction  and  magnitude  of  the  laptop  inputted  command,  the  lA  page  shows  what,  if  any, 
data  is  being  sent  for  display  on  the  laptop  using  the  10  float  variables  built  into  the 
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Figure  37.  PC_S_C30  Laptop  Display 
Window 


Figure  38.  Voice  Control  lA  Interface 
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PC_S_C30  program.  During  lab  testing  it  was  determined  that  GPS  latitude,  longitude 
and  altitude  should  be  displayed,  thus  variables  1-3  are  now  used  for  this  information. 
This  page  also  features  the  switch  that  allows  the  laptop  computer  to  control  the  FROG 
aircraft.  Two  variable  gains  were  added  to  the  system  to  magnify  the  incoming  lateral  and 
longitudinal  commands.  This  is  done  with  a  simple  SystemBuild  algebraic  block  as 
depicted  in  Figure  39.  These  gain  controls  allow  the  user  to  set  the  amount  of  control 
surface  deflection  that  standard  and  half  standard  rate  commands  produce.  The  default 
values  for  these  gains  were  be  determined  during  flight  test. 


voice  lat 


j-^ voice  long _ 

|-g^voice  lat  gain 
j-^voice  long  gain 


full  rate  limits 

[voice  dpsi 


Yl=  U1*U3 
Y2=  U2*U4 


voice  vsi 


{T> 


Figure  39.  Voice  Commands  Variable  Gain  Block 


2.  ViA  Wearable  Computer 

The  ViA  Wearable  Computer  (Figure  40)  is  a  fully  functional  microprocessor 
based  computer  packaged  in  a  highly  mobile,  physically  flexible  form.  It  is  capable  of 
running  software  based  on  the  DOS,  Windows  3.11  and  Windows  95  operating  systems. 
The  system  currently  used  with  the  VCS  consists  of  three  pods,  the  center  of  which 
contains  the  CPU.  The  wearable  features  a  AMD  586/133  MHz  processor  with  24  Mb  of 
DRAM.  Like  a  standard  laptop  computer,  the  wearable  can  be  configured  for  a  wide 
variety  of  applications  through  the  use  of  PC  cards.  The  two  outer  pods  each  contain  2 
PC  Card  sockets  configured  as  shown  in  Table  4.  One  socket  is  reserved  for  the  system 
disk  which  is  always  a  Type-III  340  Mb  hard  disk  card.  The  system  used  in  conjunction 
with  the  VCS  has  two  of  these  cards.  The  VCS  system  also  features  a  Netware  Wireless 
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Socket 

PC  Card  Type 

VCS  Configuration 

0 

I  or  11 

Netware  Wireless  LAN 

1 

I,  II  or  III 

340  Mb  HD 

2 

I  or  II 

Not  Used 

System  Disk 

III 

340  Mb  HD 

Table  4.  ViA  Wearable  PC  Card  Socket  Configuration 


The  VCS  wearable  is  powered  by  a  single  Duracell  DR-36  NiMH  battery  that  is 
housed  in  a  pouch  worn  on  the  waist  belt.  The  batteries  are  rechargeable  and  hot- 
swappable  with  the  use  of  two  battery  pouches  or  a  temporary  AC  power  source. 

3.  ViA  Hand  Held  Display/Audio  Headset 

The  ViA  Wearable  system  features  two  methods  of  entering  commands  during 
normal  operation.  Commands  may  be  entered  in  the  traditional  manual  method  utilizing 
the  touchscreen  or  with  voice  via  the  Audio  Headset  and  installed  recognition  software. 
The  ViA  Hand-Held  Display  (Figure  41)  is  a  640  x  480  active  matrix  LCD  panel  capable 
of  displaying  256  colors.  It  features  a  touch  overlay  that  allows  the  screen  to  be  used  as 
an  input  device.  The  Audio  Headset  operates  with  the  voice  recognition  portion  of  the 
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4. 


Wearable  Software 


Jennifer  Wightman  of  ViA  has  created  a  flight  management  program  that  is 
executed  under  Windows  95  on  the  wearable  computer  and  is  displayed  on  the  hand-held 
screen  (Figure  43).  The  software  allows  the  user  to  control  the  FROG  with  voice 
commands,  the  touch  screen,  or  a  combination  of  both.  All  major  commands  have  a 
button  on  the  display  to  serve  as  a  backup  to  the  primary  voice  control  method  of 
inputting  commands.  The  display  presents  current  flight  condition  information  as  the 
latest  voice  commands  sent  to  the  aircraft.  The  display  features  a  moving  map  that  shows 
the  position  of  the  aircraft  relative  to  the  ground  station.  The  scale  of  this  map  is 
adjustable  by  tapping  on  the  map  display  or  using  the  “SCALE  MAP”  voice  command. 
Several  voice  commands  allow  the  user  to  control  the  aircraft’s  flight  path  using  yaw  and 
climb  rate  commands  to  onboard  autopilot.  The  flight  control  commands  (Table  5) 
consist  of  two  word  phrases  to  aid  the  voice  recognition. 


VOICE  COMMAND 

ACTION  COMMANDED 

“RIGHT  STANDARD” 

Standard  rate  right  turn 

“RIGHT  HALF” 

Half  rate  right  turn 

“LEFT  STANDARD” 

Standard  rate  left  turn 

“LEFT  HALF” 

Half  rate  left  turn 

“CENTER” 

Constant  heading 

“CLIMB  FULL” 

Standard  rate  climb 

“CLIMB  HALF” 

Half  rate  climb 

“DESCEND  FULL” 

Standard  rate  descent 

“DESCEND  HALF” 

Half  rate  descent 

“LEVEL” 

Constant  altitude 

Table  5 .  Flight  Control  Voice  Commands 


5.  Real-time  Video  Capture  System 

An  additional  feature  of  the  VCS  is  the  ability  to  view  real-time  video  and  capture 
images  from  the  FROG’s  onboard  camera  (Figure  44).  The  camera,  a  commercially 
available  Canon  ES-970  8  nun  Video  Camcorder,  is  mounted  in  the  nose  of  the  aircraft 
behind  a  clear  Plexiglas  shield.  Currently  the  camera  is  fixed  and  must  be  turned  on 
before  flight.  A  future  project  will  allow  control  of  all  camera  functions  from  the  ground 
station.  The  video  output  of  the  camera  is  connected  to  a  small  transmitter/antenna 
assembly  mounted  on  the  rear  of  the  FROG’s  fuselage,  just  under  the  tail  boom. 
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Figure  44.  FROG  Camera  Installation 

The  television  signal  from  the  aircraft  is  received  by  the  same  laptop  that  is  the 
host  for  the  ViA  Wearable.  The  VCS  uses  the  Notebook  TV  system  manufactured  by 
Nogatech,  Inc.  of  Cupertino,  California.  This  system  includes  a  type  II ,  interactive  real¬ 
time  video  and  multimedia  PC  card  and  an  external  tuner  module  capable  of  receiving 

155  UHF  and  VHP  channels.  The  external  tuner  module  and  its  available  connections 
are  illustrated  in  Figure  45. 


Figure  45.  Notebook  TV  External  Tuner  [Ref.  8] 


The  Notebook  TV  system  is  capable  of  displaying  full  motion  video  and  capturing 
30  frames  per  second  at  a  resolution  of  320  x  240  pixels.  It  is  also  capable  of  hi- 
resolution,  24  bit  still  image  capture  at  640  x  480  pixels.  The  system  comes  with 
software;  however,  ViA  has  incorporated  the  Notebook  TV  drivers  into  the  VCS 
software.  The  VCS  software  provides  for  viewing  and  capturing  of  stills  only.  Images 
are  captured  and  displayed  on  the  touchscreen,  in  the  small  box  on  the  upper  right  side  as 
depicted  in  Figure  43,  by  issuing  the  “GRAB  IMAGE”  command.  Once  a  still  is 
captured,  it  may  be  viewed  in  the  larger  map  display  box  by  issuing  the  command 
“VIEW  IMAGE”,  tapping  on  the  image  box  twice,  or  depressing  the  image  button  icon. 
The  user  may  save  the  image  by  issuing  the  command  “SAVE  IMAGE”  or  by  depressing 
the  save  icon  on  the  touchscreen.  Any  number  of  images  may  be  saved;  each  is  given  a 
sequential  number  starting  at  1.  The  user  may  return  to  the  default  display  by  issuing  the 
“VIEW  MAP”  command,  by  tapping  twice  on  the  displayed  image,  or  deselecting  the 
image  pushbutton. 

C.  HARDWARE  IN  THE  LOOP  TESTING 

All  hardware  in  loop  testing  was  conducted  at  the  UAV  laboratory  facility  at  the 
NPS  Golf  Course.  The  FROG  flight  vehicle  was  set  up  with  wings  on  to  allow 
observation  of  the  control  surfaces.  The  RPSW CS  was  assembled  and  thoroughly  tested. 
Once  up  and  running,  all  voice  and  touch  screen  commands  were  tested.  The  flight 
control  commands  were  issued  and  the  resulting  flight  control  deflection  observed.  The 
variable  aileron  and  elevator  deflection  gains  were  adjusted  to  obtain  the  desired  surface 
deflections.  These  best  guess  numbers,  relying  on  the  experience  of  the  UAV  pilot, 
served  as  a  starting  point  for  the  flight  test.  The  video  capture  system  was  tested  to 
ensure  the  wearable  was  able  to  grab,  display  and  save  still  images.  All  VCS  functions, 
with  the  exception  of  the  moving  map,  were  successfully  tested  in  the  laboratory  setting. 
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The  moving  map  did  not  operate  as  designed  because  LTP  position  information  was  used 
to  attempt  display  the  aircraft’s  position.  The  electronic  map  utilizes  standard  latitude 
and  longitude  measurements.  A  newer  version  of  the  VCS  software  has  fixed  this 
incompatibility. 

D.  FLIGHT  TESTING 

Flight  testing  was  conducted  the  following  day  at  the  Chualar  airfield.  The  RPS 
and  VCS  components  were  assembled  and  the  same  tests  performed  in  the  laboratory 
were  repeated.  The  only  problem  was  with  the  GPS  tracking;  the  aircraft  symbol  did  not 
show  up  on  the  map  display.  This  was  due  to  the  use  of  GPS  LTP  information  vice  GPS 
latitude  and  longitude  to  fix  the  aircraft’s  position.  This  anomaly  will  be  corrected  in  a 
future  version  of  the  software. 

Weather  conditions  were  good  with  the  exception  of  a  15  knot  wind  out  of  the 
north.  The  ambient  noise  level  was  high  due  to  the  presence  of  several  construction 
vehicles  repairing  the  El  Nino  damaged  bank  of  the  Salinas  River,  located  50  yards  from 
the  airfield.  After  launch  the  aircraft  was  positioned  to  fly  a  north/south  race  track 
pattern.  Once  handed  over  to  the  computer,  the  aircraft  was  successfully  flown  for 
several  minutes  utilizing  voice  commands. 

1.  Flight  Test  Results 

The  ViA  wearable  and  voice  recognition  software  performed  exceptionally  well. 
Once  the  user  determines  the  proper  microphone  placement  and  speaking  volume  level, 
the  software  recognized  almost  100%  of  voice  commands.  This  result  was  obtained 
despite  the  presence  of  major  construction  immediately  adjacent  to  the  test  area. 

The  system  exhibited  a  two  second  delay  between  the  voice  command  and  the 
command  transmission.  This  is  due  to  the  time  required  by  the  voice  recognition 
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software  to  decipher  the  command.  This  delay  is  affected  by  many  factors  and  is  slightly 
longer  when  the  image  capture  capability  is  enabled.  The  delay  required  a  little  practice 
by  the  operator  to  be  come  proficient  at  anticipating  commands  and  leading  turns  in  order 
to  get  the  aircraft  to  fly  the  proper  path. 

2.  Control  Gains 

During  the  initial  voice  runs,  the  variable  gains  for  both  aileron  and  elevator 
commands  were  adjusted  to  produce  the  desired  turn  and  climb  rates  respectively.  It  was 
determined  that  the  standard  turn  needed  to  be  tighter  (smaller  radius)  thus  the  gain  was 
increased  from  8  to  10,  resulting  in  a  10°/sec  turn  rate.  Figure  46  details  the  lateral 
commands  and  resulting  aircraft  reaction  for  one  of  the  test  nms.  The  top  graph 
represents  the  input  command  from  the  VCS  before  it  is  augmented  by  the  variable  gain. 
A  value  of  one  represents  a  standard  rate  right  turn;  negative  one  a  standard  rate  left  turn. 
The  middle  graph  is  the  resulting  PWM  transmitted.  The  final  graph  shows  GPS  heading 
and  demonstrates  that  the  aircraft  does  indeed  turn  in  the  direction  commanded. 

Figure  47  details  the  longitudinal  results  for  the  same  run.  Here,  a  value  of 
negative  one  represents  a  full  climb;  -.5  represents  a  half  rate  climb.  It  was  determined 
that  the  initial  gain  did  not  provide  enough  elevator  authority  in  the  negative  (up) 
direction.  The  middle  graph  of  Figure  47  shows  an  slight  increase  in  PWM  as  the  gain  is 
increased.  A  final  value  of  -1350  was  determined  to  be  adequate.  The  third  graph 
demonstrates  that  the  aircraft  reacted  properly  to  the  climb  command.  It  also  shows  the 
aircraft  did  not  achieve  the  1350  ft/min  climb  commanded.  This  result  is  due  to  the  fact 
the  aircraft  was  constantly  in  a  turn  to  stay  within  the  range  limits  of  the  Futaba  controller 
and  the  visual  limit  of  the  computer  operator.  More  testing  is  necessary  to  determine  if  a 
gain  value  of -1350  corresponds  to  a  climb  rate  of  1350  ft/min  in  level  flight. 
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3. 


Turn  Performance 


The  FROG  aircraft  initially  tended  to  descend  during  voice  controlled  turns.  This 
was  due  to  the  lack  of  elevator  commands  to  increase  the  g  on  the  aircraft  during  the  turn. 
The  operator  compensated  for  this  by  commanding  a  half  rate  climb  immediately  before 
the  turn  and  level  just  after  the  turn. 

The  control  scheme  for  turns  was  improved  by  automatically  commanding 
elevator  with  the  turn  commands.  This  provides  the  necessary  g  to  allow  the  aircraft  to 
complete  the  turn  without  descending.  It  also  relieves  the  operator  from  having  to 
remember  to  command  the  elevator  before  and  after  each  turn. 

4.  Image  Capture 

The  image  capture  system  worked  as  designed.  The  quality  of  the  image  was 
poor  due  to  intermittent  reception  of  the  TV  signal  at  the  ground  station.  Further  testing 
is  necessary  to  determine  whether  this  anomaly  is  due  to  the  TV  transmitter  or  the  receive 
antenna. 


5.  Summary 

Overall,  the  VCS  was  very  successful  in  providing  control  commands  to  the 
aircraft.  The  voice  recognition  software  proved  very  reliable.  The  ViA  wearable  was 
easy  to  setup  and  use.  With  a  little  fine  tuning,  the  VCS  will  become  the  preferred 
method  for  controlling  the  FROG  UAV. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


The  projects  described  in  this  thesis  have  demonstrated  the  viability  and 
versatility  of  the  rapid  prototyping  concept.  The  time,  resource  and  money  saving 
potential  of  rapid  prototyping  is  just  beginning  to  be  explored.  The  NFS  RPS  has  allowed 
my  participation  in  two  extensive  control  projects  from  the  initial  design  to  the  final  flight 
testing  stage  over  a  period  of  about  7  months.  While  the  products  of  these  projects  are 
strictly  research  oriented,  it  is  easy  to  extend  the  method  to  actual  production  systems. 

The  work  I  have  performed  has  lead  me  to  formulate  a  few  ideas  on  how  to 
improve  the  RPS  system  in  general,  and  the  products  of  these  two  projects  in  particular. 
It  is  hoped  that  these  recommendations  will  be  helpful  to  the  endeavors  of  future  students 
who  choose  to  pursue  projects  in  rapid  prototyping. 

A  IMPROVEMENTS  TO  THE  RPS 

The  RPS  system  developed  by  the  NPS  Aero  Department  is  exceptionally  helpful 
in  the  realization  of  control  and  navigation  systems  for  the  departments  UAV  fleet. 
However,  there  are  a  few  areas  where  the  ease  of  use  and  reliability  of  the  system  can  be 
improved. 


1.  Sun  Workstation/AClOO 

The  equipment  to  do  this  is  already  on  hand.  The  portability  of  the  system  will  be 
greatly  enhanced  when  the  Sun/Luggable  combination  is  replaced  by  a  laptop  and 
AC  104.  I  recommend  that  the  first  priority  of  the  next  students  working  with  the  RPS  be 
to  get  the  new  system  up  and  running. 
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2. 


Comm  Box/Modified  Futaba  Transmitter 


These  two  components  are  the  weak  link  in  the  system.  The  four  ribbon  cables 
that  connect  the  Luggable  I/O  boards  to  the  various  components  of  the  Comm  Box  are 
fragile  and  have  had  problems  with  bent  pins.  All  connections  in  and  out  of  the  Comm 
Box  need  to  be  robust  connectors  permanently  mounted  on  the  sides  of  the  box. 

The  Modified  Futaba  Transmitter  has  also  been  less  than  completely  reliable, 
experiencing  intermittent  failures  in  its  ability  to  transmit  PWM  commands.  A  duplicate 
transmitter  that  can  serve  as  a  backup  is  needed. 

3.  Airfield 

The  airfield  at  Chualar  is  too  far  away  to  be  convenient.  NFS  Aero  needs  to 
reexamine  the  availability  of  the  Marina  Municipal  Airport;  or  perhaps,  locate  a  site  on 
the  former  Fort  Ord  property.  The  50  mile  round  trip  to  Chualar  uses  up  too  much  time, 
too  many  resources,  and  makes  a  quick  trip  back  to  campus  to  retrieve  a  spare  or 
forgotten  part  a  major  undertaking. 

B.  AIRSPEED  CONTROLLER 

In  its  current  configuration  the  Airspeed  Controller  does  an  excellent  job  in 
maintaining  a  constant  indicated  aircraft  speed.  The  following  refinements  would  make 
the  controller  more  versatile  and  user  friendly. 

1.  Integrated  Flight  Management  Page 

The  throttle  controls  need  to  be  integrated  into  a  new  main  flight  lA  interface. 
The  current  page  is  too  complex  and  does  not  include  all  of  the  control  inputs  to 
efficiently  direct  the  aircraft. 
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2. 


Control  Groundspeed 


The  Airspeed  Controller  should  be  modified  to  give  the  user  the  choice  of  using 
the  GPS  velocity  as  the  feedback  signal.  This  would  allow  the  aircraft  to  maintain  a 
constant  groundspeed,  useful  in  trajectory  control.  The  limited  airspeed  range  of  the 
FROG  aircraft  will  have  to  be  taken  into  account  when  trying  to  control  groundspeed  in  a 
high  wind  environment. 

C.  VOICE  CONTROL  SYSTEM 

The  ViA  wearable  and  voice  recognition  software  proved  highly  successful  under 
adverse  conditions.  The  system  proved  reliable  and  easy  to  use.  One  issue  with  the 
hardware  display  must  be  addressed.  Also,  the  interface  with  the  RPS  and  commands 
provided  by  the  VCS  to  the  aircraft  could  be  slightly  refined  to  improve  system 
performance. 


1.  ViA  Touchscreen 

The  touchscreen  is  a  great  tool  but  is  very  hard  to  read  outdoors;  almost 
impossible  in  direct  sunlight.  This  creates  safety  of  flight  issues  if  the  operator  does  not 
receive  feedback  on  the  commands  issued  to  the  aircraft  or  its  reaction  to  those 
commands.  ViA  is  promising  a  sunlight  readable  screen  with  future  versions  of  the 
wearable. 


2.  Airspeed  Control 

In  order  to  allow  complete  control  of  the  aircraft  with  the  VCS,  the  Airspeed 
Controller  must  be  integrated.  The  input  should  probably  be  via  the  touchscreen  vice 
voice  commands  so  as  no  to  overload  the  voice  recognition  software. 
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D. 


CONCLUSION 


The  preparation  of  this  thesis  has  be  a  challenging  and  rewarding  experience.  The 
Rapid  Prototyping  System  has  become  a  fairly  mature  system  and  in  combination  with 
the  Voice  Control  System  should  offer  some  exciting  opportunities  for  future  projects. 
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APPENDIX  A.  BLOCKSCRIPT  SOURCE  CODE 


This  appendix  contains  the  BlockScript  code  used  in  the  Current  Conditions  Hold 
Block  of  the  Speed  Controller.  It  freezes  the  value  of  the  selected  input  (U2)  when  the 
selected  switch  (Ul)  is  engaged. 


Inputs:  u; 

Outputs:  y; 

States:  x; 

Next_States :  xnext ; 

float  u(:),  y(:),  x(:),  xnext (:) ; 

if  u(l)  <  1  then 
for  i=l:y.size  do 
y{i)  =  u(i+l); 

xnext(i)  =  u{i+l); 
endf or ; 
else 

for  i=l:y.size  do 
xnext ( i )  =  x ( i ) ; 
y(i)  =  x(i) ; 
endfor ; 
endif ; 
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APPENDIX  B.  RESULTS  OF  AIRSPEED  CONTROLLER 
SIMULATIONS  IN  XMATH/SYSTEMBUILD 

The  following  pages  detail  the  results  of  several  simulation  runs  of  the  Airspeed 
Controller  as  described  in  Chapter  III.  The  first  four  runs  show  the  results  of  no  wind 
situations.  More  interesting  are  remaining  runs  which  show  the  controller  in  several  head 
and  tailwind  scenarios.  The  long  runs  are  provided  to  illustrate  that  the  controller 
maintains  a  constant  aircraft  speed  after  a  significant  amount  of  time.  The  final  run 
displays  the  differing  reactions  of  the  controller  to  the  same  inputs  in  no  wind  and 
headwind  situations. 
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No  Wind,  No  User  Speed  Inputs 


OL/CL 

Switch  Engaged 
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VelCmd  CLVelCmd  CLVelln  OL  Vel  Cmd  FROG  Velocity 


No  Wind,  +5  Knot  Speed  Change 


OL/CL 

Switch  Engaged 
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No  Wind,  +  15  Knots  Speed  Change 


OL/CL 

Switch  Engaged 
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VelCmd  CLVelCmd  CLVelln  OL  Vel  Cmd  FROG  Velocity 


No  Wind,  -  2.5  Knot  Speed  Change 


OL/CL 

Switch  Engaged 
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CL  Vel  Cmd  CL  Vel  In  OL  Vel  Cmd  FROG  Velocity 


10  ft/s  Headwind,  -  No  User  Speed  Inputs 


OL/CL 

Switch  Engaged 
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Vel  Cmd  CL  Vel  Cmd  CL  Vel  In  OL  Vel  Cmd  FROG  Velocity 


10  ft/s  Headwind,  +5  Knot  Speed  Change 


oiycL 

Switch  Engaged 
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CL  Vel  Cmd  CL  Vel  In  OL  Vel  Cmd  FROG  Velocity 


10  ft/s  Headwind,  +15  Knot  Speed  Change 


0I7CL 

Switch  Engaged 
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Vel  Cmd  CL  Vel  Cmd  CL  Vel  In  OL  Vel  Cmd  FROG  Velocity 


10  ft/s  Tailwind,  +5  Knot  Speed  Change 


OL/CL 

Switch  Engaged 
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T  rainer 
Switch  Engaged 


30  ft/s  Tailwind,  +5  Knot  Speed  Change 


OL/CL 

Switch  Engaged 
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Variable  Headwind,  +5  Knot  Speed  Change 


APPENDIX  C.  FLIGHT  TEST  EQUIPMENT  SETUP  AND 
OPERATIONAL  PROCEDURES 

This  appendix  is  included  for  the  benefit  of  future  students.  Included  is  a  list  of 
the  equipment  that  must  be  transported  to  the  airfield  for  each  flight  test.  Also  included 
are  instructions  for  setting  up  the  equipment  and  preparing  the  aircraft  for  flight  test. 


RPS  Component  Checklist 


Basic  System 

Students  Responsibility 

_  SPARC2CPU 

_  Monitor 

_  Monitor  Cable 

_  Keyboard 

_  Mouse 

_  Mouse  Pad 

_  Hard  Disk 

_ Hard  Disk  Cable 

_  Ethernet  Transceiver  and  Cable 

_  Luggable  Computer 

_  Communications  Box 

_  Futaba  Battery  for  RX  (2) 

_  Modified  Futaba  Transmitter 

_  Comm  Box  to  Futaba  Cable 

_  Trainer  Cable  (2) 

_  Antenna  Cables  for  Freewaves 

_  GPS  Antenna  and  Cable 

_  Anteima  Array 

_  Antenna  Stand 

_  12  Volt  Power  Supply 

_  Generator 

_  Generator  Power  Cord 

_  Power  Cords  (3) 

_  Power  Strip  w/  4  Power  Cords 
_  Basket  w/  extra  parts 
_  Flight  Test  Log 


UAV  Pilots  Responsibility 

_  FROG  Aircraft 

_  Futaba  Transmitter/Batteries 

_  Aircraft  Fuel 

_  Starter 

_  Starter  battery 
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Additional  Items  for  Voice  Control 


Additional  Items  for  Video  System 


Laptop  Computer 
ViA  Wearable  Computer 
Nogatech  PC  Card 
NogatechTVRX 
RF  LAN  PC  Card 
RFLANRX 


Camera  Battery(2) 

Battery  Charger  and  AC  Adapter 

Big  Antenna 

Small  Antenna 

Antenna  Cables 

RF  Down  Converter 

DC  Cables  (2) 

8  mm  and  VHS  Tapes 
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Ground  Station  Setup  Procedures 


SPARC  Setup 

1 .  Hook  up  Monitor  and  Hard  Disk 

2.  Keyboard  Connected  in  2nd  port  from  right 

3.  Coimect  to  Luggable  w/  Ethernet  Transceiver/cable 

Luggable  Setup 

1 .  Connect  Keyboard 

2.  CAREFULLY  Connect  4  Ribbon  Cables  to  Comm  Box 

Comm  Box  Setup 

1 .  Connect  Antenna  Cables 

a.  Antenna  directly  to  GPS 

b.  Two  Freewave  Cables  on  side  of  box 

2.  Ensure  3  switches  Off,  connect  Power  Supply 

3.  Connect  Cable  to  modified  Futaba  TX 

4.  Connect  Battery  to  Futaba  RX 

5.  Connect  Serial  Cable  to  Laptop 

Antenna  Setup 

1 .  Connect  Cables  to  Freewave  Helix  Anteimas 

2.  Place  GPS  Antenna  on  metal  rings 

3.  Place  Antenna  Array  onto  of  survey  marker 

Modified  Futaba  TX  Setup 

1 .  Connect  Cable  from  Comm  Box 

2.  Connect  Trainer  Cable 

Power  UP  Procedures 

1 .  Ensure  all  Boxes  are  OFF  and  connect  power  cables 

2.  Turn  ON  Power  Supply  and  set  to  12  volts 

3.  Turn  ON  switches  on  side  of  Comm  Box 

4.  Turn  ON  Computers  and  Hard  Disk 
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Preflight  Checks 


Control  Checks 

1 .  Check  and  ensure  pilot’s  Futaba  TX  moves  all  control  surfaces. 

Trim  Checks 

1 .  Connect  pilot’s  TX  to  Modified  TX  with  Trainer  Cable 

2.  Select  Trainer  Switch  and  observe  reaction  of  control  surfaces  and  actuators 

3.  Adjust  trim  until  no  movement  is  detectable  with  selection  of  TR  Switch. 

Calibrate  DAC 

1 .  Select  Trainer  Switch 

2.  Select  CAL  Mode  on  Calibrate  DAC  lA  page. 

3.  Adjust  input  and  record  values  for  2.4  and  2.7  volts  for  desired  controls. 

4.  Enter  values  in  slider  control  inputs 

5.  Deselect  CAL  Mode. 

Other  Checks 

1 .  Look  at  GPS  and  IMU I A  pages  to  ensure  receiving  data. 

2.  Turn  on  Video  camera  and  transmitter  and  check  TV  reception. 

Warm  up  checks 

1 .  Start  engine  and  warm-up  for  5  minutes 

2.  Perform  high  speed  taxi  test 

Takeoff 

1 .  Start  timer  to  track  time  airborne 

2.  Record  data  via  lA  page 

3.  Start  VCR 
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